The protection of data networks is currently provided by devices the security of which depends on the security of their implementation and the correct compliance with communication protocols. This is particularly the case for “firewall” devices, application relays or products segmenting the networks (such as VLAN products or the 802.IQ standard), as well as systems for the detection and prevention of intrusion.
Several types of secure architectures can exist. In highly secure architectures, network interconnections are prohibited. Exchanges are carried out using physical elements that are attached from system to system. Unidirectional communication exchange devices exist but their reliability is limited because of the lack of exchange of control flows. This is the case of “physical diode” devices mostly based on fibre optic technologies.
An example of an ideal secure exchange architecture is shown in FIG. 1A. In the network shown in this figure, access to the data system IS from a system having a different level of confidence, in this case a public network PUB, is carried out via firewalls FW1, FW2, FW3, FW4 delimiting an external exchange zone DMZout, an internal exchange zone DMZint and an extended exchange zone DMZext respectively managed by dedicated servers SERVout, SERVin and SERVext. Additional servers SERVadm and SERVsav are used for administrative and saving operations respectively. The multiplication of these exchange zones allows the task of a possible malicious user wishing to gain access or even to corrupt certain data of the data system IS to be made more complex.
Another “conventional” example of secure exchange architecture is shown in FIG. 1B. It again uses the “exchange zone” concept previously defined in “ideal” exchange architectures, but simplifies it to the extreme in order to have no more than one or two exchange zones DMZout(A) and DMZout(B).
However, many software faults have been noted in this type of architecture, then resulting in compromising the network which it was supposed to protect. The “ideal” architectures have, for example, been vulnerable to attacks on applications using web-services. The conventional architectures are themselves vulnerable to any use of hidden channels (declaration of use of a given protocol in order to mask the real use of another protocol or of a protocol highjack).
Independently of this problem of software security, a poor application of a company's security policy or an error in the configuration of such devices can compromise the security of the entire network. These errors therefore necessitate monitoring and procedures for audits and continuous upgrading of such devices.